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SYSTEM FOR REMOTE COMMUNICATION WITH AN IMPLANTABLE MEDICAL DEVICE 



FIELD OF THE INVENTION 

The present invention relates to medical devices and, particularly, to a system 
and method for the remote communication with a medical device. 

BACKGROUND OF THE INVENTION 

Medical devices are currently implanted in a variety of patients for a variety of 
reasons. Such medical devices may include, without limitation, drug pumps, nerve 
stimulators, cardiac defibrillators, as well as cardiac pacemakers. Once implanted, 
many of these medical devices require the download of data collected by the medical 
device, the reprogramming of the medical device or the interrogation of the medical 
device to ensure proper operation, among others. 

Subsequent communication with an already implanted medical device 
generally requires the use of a programmer. Programmers are devices which permit 
the downlink to be made from the programmer to the medical device as well as the 
receipt of a subsequent uplink from the medical device to the programmer. Often the 
programmer is placed within the hospital or physician's office so that the physician is 
directly next to the patient while the communication with the medical device is made. 
Thus, present devices often require the patient to travel directly to the hospital or 
doctor's office to permit the communication to be made with the medical device. 

Such travel, merely for the communication with the medical device, may 
sometimes be a problem. Patients may live in a variety of locations, including such 
remote locations as islands, mountainous areas or other areas of the world where both 
travel is difficult as well as remote from the particular physician's office, Moreover, 
on occasion the attending physician may desire additional input or guidance for the 
data received from the medical device and the subsequent reprogramming. 

In view of the above, there exists the need for a system that permits remote 
communication with a medical device. There exists a further need for such remote 
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communication to be permissible such that one or more device experts such as 
physicians and more experienced device users may be aware of the communication 
and provide guidance for the subsequent interpretation and programming of the 
device. 

SUMMARY 

A system permitting the remote communication with a medical device. The 
system particularly may permit the remote communication such that one or more 
device experts such as physicians and more experienced device users may be aware 
of the communication and provide guidance for the subsequent interpretation and 
programming of the device. The system may include a medical device adapted to be 
implanted into a patient; a server PC communicating with the medical device, the SPC 
having means for transmitting data across a dispersed data communication pathway 
(Internet); anda client PC having means for receiving data transmitted across a 
dispersed communication pathway from the SPC. In certain configurations the the 
server PC may have means for transmitting data across a dispersed data 
communication pathway (Internet) along a first channel and a second channel; and the 
client PC may have means for receiving data transmitted across a dispersed 
communication pathway from the SPC along a first channel and a second channel. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIGs. 1 A & IB depicts an overview of the system according to the present 
invention. 

FIGs. 2A & 2B depict further embodiments of the system according to the 
present invention. 

FIGs. 3 A & 3B are schematic block diagrams of the steps undertaken for the 
communication with a medical device using the system of the present invention. 
FIG. 4 depicts a safety feature of the present invention. 

FIG. 5 depicts the steps used to permit the authorized level client usage in the 
programmer. 
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FIG. 6 depicts the various types of information transferred between client, 
server and device as well as the protocol used for the transmission. 

FIG. 7 shows a system operation for checking information received along the 
second data channel. 

FIG. 8 shows basic steps used between a client, server and programmer to 
transmit a command. 

FIG. 9 depicts an additional system to the present system. 

FIG. 10 depicts the steps used to permit a variety of different clients to be 
logged in to a single server. 

FIG. 1 1 illustrates a system substantially like that shown in FIG. 1 A but also 
featuring a time & autocorrelator 111 communicating with a signal receiver 1 12 and 
signal generator 1 13 in client. 

FIG. 12 depicts an alternative embodiment. 

The FIGS, are not necessarily to scale. 

DETAILED DESCRIPTION OF THE DRAWINGS 

The present invention relates to a system and method for remote 
communication with a medical device. This system particularly takes advantage of 
the Internet. 

The Internet, sometimes called simply "the Net," is a worldwide system of 
computer networks - a network of networks in which users at any one computer can, if 
they have permission, get information from any other computer (and sometimes talk 
directly to users at other computers). It was conceived by the Advanced Research 
Projects Agency (ARPA) of the U.S. government in 1969 and was first known as the 
ARPANet. The original aim was to create a network that would allow users of a 
research computer at one university to be able to "talk to" research computers at other 
universities. A side benefit of ARPANet's design was that, because messages could 
be routed or rerouted in more than one direction, the network could continue to 
function even if parts of it were destroyed in the event of a military attack or other 
disaster. 
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Today, the Internet is a public, cooperative, and self-sustaining facility 
accessible to hundreds of millions of people worldwide. Physically, the Internet uses 
a portion of the total resources of the currently existing public telecommunication 
networks. Technically, what distinguishes the Internet is its use of a set of protocols 
called TCP/IP (Transmission Control Protocol/Internet Protocol). Two recent 
adaptations of Internet technology, the intranet and the extranet, also make use of the 
TCP/IP protocol. 

The Internet Protocol (IP) is a protocol or method by which data is sent from 
one computer to another on the Internet. Each computer (known as a host) on the 
Internet has at least one address that uniquely identifies it from all other computers on 
the Internet. When you send or receive data (for example, an e-mail note or a Web 
page), the message gets divided into little chunks called packets. Each of these 
packets contains both the sendees Internet address and the receiver's Internet address. 
Any packet is sent first to a gateway computer (router) that understands a small part of 
the Internet. The gateway computer reads the destination address and forwards the 
packet to an adjacent gateway that in turn reads the destination address and so forth - 
across the Internet until one gateway recognizes the packet as belonging to a computer 
within its immediate neighborhood or domain. That gateway then forwards the 
packet directly to the computer whose address is specified. 

Because a message is divided into a number of packets, each packet can, if 
necessary, be sent by a different route across the Internet. Packets can arrive in a 
different order than the order they were sent in. The Internet Protocol just delivers 
them. It's up to another protocol, the Transmission Control Protocol (TCP) to put 
them back in the right order. 

IP is a connectionless protocol, which means that there is no established 
connection between the end points that are communicating. Each packet that travels 
through the Internet is treated as an independent unit of data without any relation to 
any other unit of data. (The reason the packets do get put in the right order is because 
of TCP, the connection-oriented protocol that keeps track of the packet sequence in a 
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message.) In the Open Systems Interconnection (OSI) communication model, IP is in 
layer 3, the Networking Layer. 

The most widely used version of IP today is Internet Protocol Version 4 
(IPv4). However, IP Version 6 (IPv6) is also beginning to be supported. IPv6 
provides for much longer addresses and therefore for the possibility of many more 
Internet users. IPv6 includes the capabilities of IPv4 and any server that can support 
IPv6 packets can also support IPv4 packets. 

UDP (User Datagram Protocol) is a communications method or protocol for 
communication which offers a limited amount of service when messages are 
exchanged between computers in a network that uses the Internet Protocol (IP). UDP 
is an alternative to the Transmission Control Protocol (TCP) and, together with IP, is 
sometimes referred to as UDP/IP. Like the Transmission Control Protocol, UDP uses 
the Internet Protocol to actually get a data unit (called a datagram) from one computer 
to another. Unlike TCP, however, UDP does not provide the service of dividing a 
message into packets (datagrams) and reassembling it at the other end. Specifically, 
UDP doesn't provide sequencing of the packets that the data arrives in. This means 
that the application program that uses UDP must be able to make sure that the entire 
message has arrived and is in the right order or that the mis-ordering or loss of data is 
not of consequence. Network applications that want to save processing time because 
they have very small data units to exchange (and therefore very little message 
reassembling to do) may prefer UDP to TCP. The Trivial File Transfer Protocol 
(TFTP) uses UDP instead of TCP. 

UDP provides two services not provided by the IP layer. It provides port 
numbers to help distinguish different user requests and, optionally, a checksum 
capability to verify that the data arrived intact. 

Computers that are on the Internet utilizing TCP/IP protocol are usually so 
called open systems continuously connected within the local area network 
infrastructure. Hubs are used for these mutual connections, while specialized 
computers, routers or gateways, are used for linking LANs over the long distances. 
Computers may be continuously connected to the leased line dedicated for Internet 
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traffic or they may be connected on-demand via modems and telephone lines. 

However, there are many computers which temporarily become a part of the Internet 

utilizing the dial-up connection. This kind of Internet connection is usually done 

from home. The low-level protocols used to carry Internet traffic over a dial-up 

connection are called SLIP (Serial Line Internet Protocol) and PPP (Point-to-Point 

Protocol). In comparison with the full-time connection, this kind of connection is 

slower. Nevertheless, ISDN (Integrated Services Digital Network) becomes available 

even at homes, offering higher speeds than the standard modem connection. While 

the connection speed between the two IP addresses is much higher through the 

dedicated full-time connection, the connection speed may be slowed down due to the 

intensive traffic on the network wherein many users send and receive the data. 

Routers and hubs usually treat the users to have equal priority and distribute the traffic 

throughout the network in order to achieve the best throughput rate utilizing the free - 

network resources. Therefore sometimes intermittent interruption of the data - - & 

transmission and reception may occur and the average throughput rate may be very 

low on the busy network. 

Accordingly, the throughput rate between the two computers may be faster and r? 
more reliable utilizing dial-up connection. This is because of the fact that hubs and . . . if 

routers are avoided utilizing direct telephone line connection by means of the modem 
or the ISDN interface. In dial-up connection, the telephone line is reserved only for 
the TCP/IP traffic between the two computers. 

At present, the most convenient computer platform and language for 
implementation of this invention is Java™ which may be provided by Sun 
Microsystems, Inc. Inc., San Jose, Calif. Java is a high-level object-oriented 
interpreted programming language being architecture-neutral and portable. Java has 
a compiler for translating a Java program into an intermediate language called Java 
bytecodes, the platform-independent codes interpreted by the Java interpreter. With 
an interpreter, each Java bytecode instruction is parsed and run on the computer. 
Compilation happens just once; interpretation occurs each time the program is 
executed. Java bytecodes are like the machine code instructions for the Java Virtual 
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Machine (Java VM). Every Java interpreter, whether it's a Java development tool or 
a Web browser that can run Java applets, is an implementation of the Java VM. The 
Java VM can also be implemented in hardware. The Java platform has two 
components: the Java Virtual Machine (Java VM) and the Java Application 
Programming Interface (Java API). The Java API is a large collection of ready-made 
software components that provide many useful capabilities, such as graphical user 
interface (GUI) widgets. The Java API is grouped into libraries (packages) of related 
components. Probably the most well-known Java programs are Java applets. An 
applet is a Java program that adheres to certain conventions that allow it to run within 
a Java-enabled browser. Common type of Java programs are also applications, where 
a Java application is a standalone program that runs directly on the Java platform. A 
special kind of application known as a server, serves and supports clients on a 
network. Another specialized programs are servlets which are similar to applets in 
that they are runtime extensions of applications. Instead of working in browsers, 
though, servlets run within Java servers, configuring or tailoring the server. Huge 
variety of implementations of this invention, which may be done utilizing Java 
platform and language, prevents to precisely disclose all of the aspects. The 
following figures are only examples for illustration, but an expert skilled in the art 
may use Java in numerous different possible modes because it is among the most 
dynamic, simple and multithreaded computer platform and language. 

FIG. 1 A depicts an overview of one system according to the present 
invention. Due to the fact that the system should operate within the computer 
network, it may be, but not necessarily, built as a client/server configuration. The 
Internet is based upon data which may be offered to client computers which can hook- 
up to the various kinds of servers - ftp, wais, web etc. A typical client is the PC 
comprising web browser software. Since the occurrence of Java platform, the 
possibility to share the complexity of the specific software task is particularly 
attractive by exchange of the applets. Moreover, special server application and special 
client application open the possibility that the hardware and processing resources are 
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shared in such a way as to optimize the tasks for the particular implantable device 
programming session. 

As seen, the system has essentially five primary components. Medical device 
1 may be of any type which provides therapy to a patient or information collection so 
long as the device has the ability for communication (unlink and downlink) to an 
external device, seen here as programmer 2. Medical device may, for example only 
and without limitation, comprise a Medtronic Kappa 400 DDDR pacemaker. 
Programmer 2 may, again, be of any acceptable design which permits linkage to a 
medical device including the Medtronic 9790 programmer. 

The server is a computer which permits the transfer of information, including 
data and commands, from device 1 , programmer 2 and server 3 to client 4 through a 
dispersed network, depicted here as Internet 5. In the preferred embodiment network 
traffic flows between client and server through two separate data streams 10 and 11. 

First data stream 1 0 transmits information which has been divided into . 
discrete information packets wherein control messages and state updates between the 
server and the client are comprised. In the preferred embodiment, first data stream 10 
transmits information using the TCP/IP network protocol containing both the sender's 
Internet address as well as the receiver's address. If dial-up connection is used, one 
of the low-level protocols are used (either SLIP or PPP). Regardless of the specific 
protocol used, first data stream is designed so that information (such as data or 
commands) which is sent from one computer to the other has a receipt which is sent in 
the opposite direction so that the transmission of the information is verified. Such a 
data stream transmission is reliable but has a relatively slow rate of data transfer. It 
warrants either delivery or failure notification, therefore being used for data such as 
commands to the server and messages to clients designating the server changes. It 
may also be used to send the calculated heart beat rate to the clients after each beat. 
As this message is sent periodically and rather often, it may serve as a periodical 
probe to measure the connection's reliability. As the Internet protocols will evolve, 
the system may be adapted utilizing the more efficient protocol such as the Internet 
Protocol Version 6. 
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Second data stream transmits information using a different protocol. As seen, 
such a protocol has the transmission in only one direction, that is, this data channel 
does not transmit information having the returned receipt request, as required in first 
data stream. For this reason second data stream is relatively faster than first data 
stream, although has a lower degree of reliability since the actual receipt of the 
information cannot always be verified. 

In the preferred embodiment, first data stream transmits commands and other 
types of information while second data stream transmits the real-time ECG waveform 
of the medical device. In the preferred embodiment, second data stream transmits 
data using User Datagram Protocol ("UDP"). As mentioned above, unlike TCP, the 
UDP does not provide the service of dividing the message into packets and 
reassembling it at the other end of the transmission. Specifically, UDP does not 
provide sequence to the packets when the data arrives. This means the programmer 
that uses UDP must make sure that the entire message has arrived and is in the right 
order or that missing or mis-ordered data is of no consequence. 

In the present invention, the second data stream is used for transmission the 
ECG, hence, the UDP data consists of only two bytes per message - one data point of 
the ECG waveform and its ordinal number. Apart from the ECG waveform, the 
cardiac therapy device could also send the IEGM, some hemodynamic parameter 
waveform such as blood pressure, blood flow, or even the ultrasound measurement 
waveform. UDP can be also used for transmission of the marker channels as well as of 
the various biochemical sensors signals. For example, within the context where the 
medical device is a nerve stimulator (similar to the Medtronic Itrel series) the device 
could transmit a EEG or EGG waveform. In fact, a nerve stimulator having the 
capability to measure the tremor intensity would transmit the signal representing the 
tremor intensity thus enabling the DBS output programming according to the tremor 
intensity. Since digitized waveforms have an inherent redundancy, in that the general 
waves are known as well as the possible values of the different parameters, missing 
data packets or missing data may be quickly identified as being actually missing, as 
opposed to indicating very low sensed and reported signal strength, or the data having 
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peculiar values. UDP packets are satisfactory for this purpose because it is not 
crucially important that every packet arrives. Missing data packets, however, should 
not normally happen on dedicated network link and therefore this event may be used 
as an additional test of the network link. That is the amount of missing data packets 

5 may be used as a parameter to indicate to the users the fidelity of the link. Such 

fidelity may be communicated through a pop-up menu or box on one or more of the 
users screens. This box may indicate that the network transmissions are not complete 
and that data is missing. Courses of action may thereafter be recommend, including 
restarting the system, or reissuing the command . It must be understood, however, that 

10 other protocols for data transfer may also be used, other than only UDP. 

. In a further embodiment regarding the data link, the delay between the data at 
the server and is receipt at the client may also be provided to one or more of the users. 
The delay display is of value to the users as it permits the basis for the lag between 
commands to be understood as possibly only a network phenomena. Delay display 

15 may be provided in may acceptable manners, including that of the UNIX command 

"traceroute." 

Here is an example of the traceroute command execution for the connection 
between the two computers in Zagreb, Croatia (maja.zesoi.fer.hr) and up to the ftp 
server of the Medtronic Inc. The measurement stopped at some security firewall of the 
20 Medtronic network which didn't allow further penetration. Delays to establish 

connection through various gateways, together with the relevant IP addresses, are 
revealed. 

traceroute to ftp.medtronic.com (144.15.255.25), 30 hops max, 40 byte packets 
1 zemsgwy (161.53.64.1) 2 ms 2 ms 1ms 
25 2 161.53.113.65 (161.53.113.65) 4ms 1ms 1ms 

3 194.152.222.97(194.152.222.97) 5 ms 6 ms 4 ms 

4 bordercore30-hssiO-l-0.WestOrange.cw.net (166.49.27.9) 445 ms 432 ms* 

5 xcore.Chicago.cw.net (204.70.150.1) 380 ms 377 ms 344 ms 

6 mci-gw.mixnet.net (204.70.186.6) 375 ms 412 ms 468 ms 

30 7 BorderO-F5-0.MSC.MR.Net (198.174.96.2) 376 ms 351ms 412 ms 
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8 * Border35-eO.MSC.MR.Net (137.192.3.35) 472 ms 381ms 

9 Medtronic- 1-MRNet.MSC.MR.Net (137.192.27.150) 359 ms 378 ms 400 ms 

10 * * * 

Accordingly, the result of the data packets delivery time, revealed by the 
traceroute command, may be directly utilized to evaluate the feasibility of the 
connection for the teleprogramming procedure. 

In a further embodiment the system may feature a communication link test 
capability. Through this capability, the system may determine whether it is in fact the 
communication link which is faulty (e.g. poor network quality) or whether it is instead 
a programming wand communication problem. This communication link test 
capability would essentially operate as follows: First a test waveform would be 
generated by the client and transmitted through the network thereby received by the 
server. 

FIG. IB depicts an overview of an alternative system according to the present 
As seen in this embodiment the system is the same as that already described in FIG. 
1 A but for the additional provision of one or more advisors or experts, each of whom 
may communicate through the server, client or the Internet. 

FIG. 2A illustrates further details of the possible system embodiment. The 
server 200 is installed in the remote clinic operated by the technician 201 . In this 
embodiment, programmer 203 having an ECG interface is a separate device and is 
connected to server 200. Patient 204 is connected by the ECG cable (not shown) to 
the interface 203 for the purpose of the ECG recording, while programming wand 205 
through an electromagnetic coupling enables, as is well know in the medicla device 
field, the communication with the implanted device (not shown). The server 200 is 
the most complex component of the system, which provides real-time data about the 
patient's state, accepts and executes the operator's commands, monitors the system's 
overall performance and reliability, resolves all dubious situations and acts in 
emergency situations. The server is designed to take all this responsibility because it 
is nearest to the patient, and failure of any of the components between it and the 
patient are least likely. It may be a standard PC computer, but also a "black box" 



WO 01/03575 



PCT/US00/17699 



12 



10 



15 



20 



25 



without special screen and command buttons which could confuse the operator 201. 
A variety of different types of devices may be used to connect server 200 to the 
Internet (which usually comprises hubs and routers which are not shown) including 
modem, ISDN or ATM interface 206. A second device is provided to connect client 
208 to the Internet. A modem 207 is illustrated as connecting client 208 to the 
Internet (of course other devices such as ISDN or ATM interface may also be used.) 
Advisor 209, being the expert for the particular therapy with the medical device, is the 
operator of the client computer 208. The client 208 shows to the operator 209 a 
graphic user interface that visually and functionally mimics the GUI of the 
implantable device programmer 203. It displays the ECG waveform of the patient, 
and comprises the controls of the ECG recording and display as well as the 
implantable device programming commands. 

FIG. 2B discloses another possible embodiment of the system . In particular 
this illustrates a system used to provide pacemaker patient remote follow-up. As seen, 
pacemaker expert 220 is in the pacemaker center operating the server computer 221 . 
Server 221 is connected to the normal telephone line appliance 223 by means of the 
modem 222. Patient 224 operates himself a device 225 being the client computer and 
the pacemaker programmer as well. Therefore it comprises a programming wand 226 
for communication with the implantable device (not shown). It may also comprise 
some kind of simple patient ECG cable (not shown) such as metal bracelets. Modem 
227 is used to connect the client 225 to the normal telephone line appliance 228. In 
this configuration, the server shows the GUI of the pacemaker programmer including 
the patient real time ECG waveform. The patient connects the ECG bracelets (not 
shown) on his arms and positions the programming wand over the implanted device. 
Client computer 225 runs previously installed device specific software application. 
Patient can initiate the call to the appropriate dial-in network number and logging into 
the server. Software application of the server 221 recognizes the client 225 and 
displays the client specific GUI on the screen of the server. The voice over data 
feature may be possible, for the purpose of the communication between the physician 
220 and the patient 224. Physician 220 can interrogate and program the implanted 
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device while monitoring the ECG waveform of the patient 224. In this embodiment, 
the client computer and the programmer should be integrated into the one low-cost 
simple device for easy application. Though client 225 is illustrated as a notebook 
computer, it should be designed as a simple "black box" without the screen 
comprising only the basic command buttons and LED signals easy operated by 
average patient. The disclosed principle of the client at the patient side and the server 
at the advisory side, may also be used in the previously disclosed Internet connection 
system. 

FIG. 3 A is a schematic block diagram of the steps undertaken for the 
communication with a medical device using the system of the present invention 
disclosed in FIG. 2 A. As seen at 3-1, the server is logged into. Thereafter, 
communication with the programmer is begun 3-2, whereby server takes the control 
over the programmer. Thereafter, at 3-3 programmer identifies medical device 
through uplinking in identified step, step 3-4, whereby device sends also the present 
status, such as those provided by the QuickLook™ feature of the Vision™ software, 
the product of the Medtronic, Inc. At 3-5 server starts the software application for the 
specific device, preferably written in Java language. At any time during the 
abovementioned period the client login takes place at 3-6 including the process of the 
user classification 3-7 (illustrated below in FIG. 5) and the client software 
application start preferably written in Java language. At 3-8 client sends the 
appropriate request to the server in order to establish the mutual communication 
whereby client gets the previously defined assignment according to the user class 
either as an advisor who can take over the follow-up control or only as an observer. 
As discussed above, this takes place via the Internet utilizing one of the various 
communication protocols, including TCP/IP. At 3-9 the server identifies the client 
user and, thereafter, authorization is provided to the client at 3-10 from the server 
including recognition of the user class and definition of the corresponding Java applet 
This is an important feature of the system as it permits users having differing access 
levels to be provided the appropriate GUI. Programmer provides the server with the 
ECG waveform of the patient at 3-1 1. Such information is obtained form the medical 
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device to the programmer in a well known manner.. The server prepares the UDP 
packets comprising the information about the ECG waveform and sends them to the 
client at 3-12 as well as the Java applet for the GUI on the client. Applet is received 
and interpreted within the client Java application at 3-13 and appropriate GUI is 
5 displayed together with the real time ECG waveform of the patient wherein authorized 

advisor has the graphic icons and buttons for the programmer control. At 3-14 a 
device interrogate command is given. This may be accomplished, for example, by 
pointing to an "Interrogate" button within the client GUI, server receives the 
command at 3-15 and the programmer requests interrogation from the implanted 

10 device at 3-16. Upon the telemetry measurements at 3-17, device may be providing 

telemetry output, seen at 3-1 8, to the programmer. As seen, telemetry received by the 
programmer at 3-1 9 is further provided to the server which prepares the appropriate 
Java applet at 3-20 providing the applet to the client via network. Client interprets 
the Java applet by its Java application software at 3-21 and displays the telemetry 

15 results and diagnostic memory content within its GUI. 

FIG. 3B is a schematic block diagram of the steps undertaken for the 
communication with a medical device using the system of the present invention 
disclosed in FIG. 2B. It is assumed for this illustration that the programmer and the 
client are a single hardware device. Of course, this is not per se required and separate 

20 and discrete devices may also be used. As seen at 3-1, the server is logged into. 

Thereafter, the server software application is begun at 3-2, whereby server waits for 
dial-up network connection call. At any time, at 3-3 the patient activates his device 
and the client application starts at 3-4. Patient puts the programming wand above the 
implanted device and client identifies medical device through uplinking in identified 

25 step, step 3-5. Patient connects the ECG cable to his body starting to record the ECG 

waveform at 3-6 supplying the client with the ECG signal at 3-7. At 3-8 client makes 
a call sending the appropriate request to the server in order to establish the dial-up 
network connection whereby starting to send a real-time ECG waveform in UDP 
packets as well as the patient data. As discussed above, this takes place via the 

30 Internet using various communication protocols, including TCP/IP. The server 
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identifies the client at 3-9 and the real-time ECG waveform is continuously displayed 
at 3-10 within the server GUI together with the all of the patient data. Client sends 
the device identification at 3-1 1 and server starts the software application for the 
specific device at 3-12. This causes the change of the GUI at 3-13 bringing display 
of the additional menus and buttons for interrogation and programming of the specific 
device. After unlink, device has automatically completed the telemetry 
measurements at 3-17. Operator of the server points to the appropriate button at 3-14 
putting an interrogation and telemetry request at 3-15 to the client through the 
network which receives and interprets this command at 3-16. As seen, diagnostic 
memory content and telemetry results are prepared at 3-18 for the processing in order 
to make a Java applet at 3-19 and to send it via network. The server receives and 
interprets the applet at 3-20 and displays the telemetry and diagnostics screen at 3-21. 
This may be the screen such as the QuickLook™ feature of the Vision™ software, the 
product of the Medtronic, Inc. 

FIG. 4 depicts a safety feature of the present invention. As can be 
appreciated, during remote communication, the remote communication link may be, 
on occasion, interrupted. Medical devices often, during such remote communication, 
are called on to perform various tests. Such tests, although generally safe, should not 
be unavoidably interrupted nor, further, should not be permitted to continue should an 
interruption occur. The steps used in FIG. 4 provide a method by which a test which 
has begun in the device may be stopped should the remote connection be interrupted. 
As seen at 4-1 , the client is logged in and a connection made at 4-2. At some time, 
thereafter, a test is begun in the device, 4-3. While the device testing is begun the 
server maintains a watch to maintain if the connection is okay, 4-4. As seen, if the 
connection is not okay, the device drops down and ends the test immediately, 4-5. If 
the connection is okay, the device drops to 4-6 where the test is continued. 
Thereafter, the device continues with the test before recycling again back to block 4-4, 
where the connection is again verified to be okay. Subsequently, upon test end, the 
device would drop through block 4-7 and the test would be ended. 
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FIG. 5 depicts the steps used to permit the authorized level client usage in the 
programmer. As seen at 5-1 , the client logs in. Subsequent to this, at 5-2, the server 
checks the client classification and user access. The server can have this information 
stored either in the server memory or, more preferably, itself access the third party 
database to permit identification of the proper client access. Thereafter, at 5-3 the 
server allows the logged in client access according to the classification of the client. 
Thereafter, the programming and device communication may continue as desired. 

FIG. 6 depicts the various types of information transferred between client, 
server and device as well as the protocol used for the transmission. As discussed 
above, the system preferably uses at least two communication channels, the first 
channel requiring a receipt returned. The second data channel, in contrast, does not 
provide a receipt that the information was properly received. As seen, the system 
preferably uses a non-receipt information protocol for information such as the QRS 
signals of a pacemaker. Such information is ongoing display information in which the 
absence of data may be readily ascertained as well as not immediately crucial to 
device operation. Other information, such as commands, are transmitted using a 
protocol in which a receipt of acceptance is provided. 

In the preferred embodiment, the first channel protocol is UDP, as mentioned 
above, while the second data channel is a TCP, also mentioned above. Other 
information transmitted using such TCP includes, in the example of a pacemaker, 
marker channel, battery voltage levels, histogram information as well as lead 
parameters. 

FIG. 7 shows a system operation for checking information received along the 
second data channel. As discussed above, the second data channel does not provide 
back to the sender a receipt. The steps used in FIG. 7 permit the sender to be 
notified by the recipient if an incorrect or improper amount of information is received 
by the receiver. As seen at step 7-1 , the receiver determines whether any information 
has been received. At 7-2 the receiver starts the dedicated signal processing for the 
purpose of the waveform analysis in order to determine whether all the data has been 
received at 7-3. Determination that all the data has been received may be provided 
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manually, by the operator, or automatically, by resident software. Such resident 
software may be any of the various types of signal processing, including morphologic 
filtering, pattern recognition, templates, etc. If yes, then the receiver continues to step 

7- 4, otherwise the receiver drops down to 7-5. At 7-5 the receiver sends a message to 
5 the sender corresponding to the type of data that is missing. In the example of a 

cardiac pacemaker, the information which may be sent in such a manner is the QRS 
signal. In this example where the QRS signal is received but some of the data seems 
to be missing according to the client, the client channels a message at 7-4 which is 
sent to the server and, thus, to the programmer that the ECG connection should be 

10 inspected. 

FIG. 8 shows basic steps used between a client, server and programmer to 
transmit a command. As seen at 8-1, a change mode command is entered by the user 
into the client. At 8-2 the change mode command is broadcast across the network or 
internet as a series of packets using an appropriate internet protocol, TCP in the 

15 preferred embodiment. At 8-3 server receives the packets and assembles them into 

the proper order. At this time the server would also send back to the client a receipt 
that the packet sent off at 8-2 has been received. At 8-4 the server interprets the 
received packets which have now been assembled as a change mode command. At 8- 
5 the change mode command is transferred to the programmer. As seen, commands 

20 are transferred to the programmer via a cable. At 8-6 the programmer executes a 

command by down linkage to the IPG which does change its mode, and which 
responds that the mode has been changed back to the programmer. At 8-7 a 
confirmation of command execution is sent back to the server again via the cable. At 

8- 8 the confirmation of command execution is broadcast across the network as 

25 packets by the server. At 8-9 the client receives the packets broadcast by the server 

and assembles them, thereafter, also interpreting and displaying the packets as a 
change mode command executed. 

FIG. 9 depicts an additional system to the present system. The present 
system permits communication to be made over dispersed mediums such as an 

30 internet. As such it permits ready access by a multiple number of clients to a single 
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server. Thus, as seen, the system could permit, in addition to client A, depicted here 
as 4 (and which is communicated with and to in the same manner as that discussed 
with regards to FIG. 1), the additional provision of client B 9-2 and client C 9-3. 
These additional clients may have varying means of access to the server and, thus, to 
the programmability of the device. For example, client B may have access to be only 
an observer while client C may be provided to be an observer/client with the 
additional ability to interrogate the device as well as do memory and telemetry read 
out. In this environment, moreover, server 3 plays a more active role. For example, 
as discussed above each client may have various level of access. To permit this, 
server 3 provides differing GUI applets to the differing authorized clients. For 
example, only one authorized client would have the possibility to control the 
programming session i.e. program the therapy device and to see the private patient 
data. Other clients would only have the possibility to observe what is the authorized 
client doing. They could also save the interrogated program and telemetry data as well 
as the ECG, IEGM and marker channel waveforms in their computers for the later 
recall for the education purpose. 

FIG. 10 depicts the steps used to permit a variety of different clients to be 
logged in to a single server. Thus, FIG. 10 depicts the steps used to achieve a system 
such as that shown in FIG. 9. At 10-1 the client logs in to the server. At 10-2 the 
server determined whether other clients are already logged in. If yes, then the server 
proceeds to 10-3 and determines whether multiple clients are permitted to be logged 
in. If not, then the client attempting to log in at 10-1 is denied access and the process 
ends, depicted here as 10-4. If, however, multiple clients are logged in 10-3, then the 
system proceeds to 10-4 where the client classification is checked. Thereafter, the 
device proceeds to 10-5 and allows the client access according to their classification. 
Thereafter, the process may continue where the client receives the information or 
commands the device, or both, as already discussed above. 

FIG. 1 1 illustrates a system substantially like that shown in FIG. 1 A but also 
featuring a time & autocorrelator 1 1 1 communicating with a signal receiver 112 and 
signal generator 1 13 in client. Also shown is a tranmsponder 1 14 in server. These 
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components may be used to provide a system which will permit a test signal routineu 
to be enabled so as to determine and therafter indicate the delay or lag in the signal. 
Either on of the client or server, or the programmer, for that matter, may thereafter be 
equipped to indicate to one or more system operators or advisor as to the speed or lag 
to the signal over the network One of the methods to exactly measure the signal 
delay is to use the RF signal of the atomic clock emitting exact coded time. For the 
two places, very far from the clock, the code is received with negligible difference in 
time and appropriate software could be used for reading the time of transmission as 
well as the time of reception. While the traceroute UNIX command would be feasible 
for the majority of applications, particularly for the continuously defined connections, 
it would never be able to evaluate the connection quality i.e. degradation of the 
signal's waveform through the network transfer. The simple method would be the 
"software transponder" such as disclosed in figure 11. Transponder is normally a 
device which sends instantly upon the signal's reception the signal back to the 
transmitter of that particular signal. It also may involve some delay which depends 
usually on electronic circuits. Nevertheless, it is usually used for the certain remote 
identification of the remote receiver. Despite of the fact that it is usually the high 
frequency hardware, it can be implemented as a software within the computer. In the 
case of the remote programming technology, the special software could be built for 
evaluation of the various delays generated throughout the network. The transponder 
may be incorporated whether in the client or in the server. The illustrated example 
discloses the client comprising the test signal generator and the test signal receiver as 
well as the timer and the autocorrelator. The server comprises the transponder. Apart 
from disclosed example it may be implemented vice versa with the transponder in the 
client and signal generator, receiver and timer-autocorrelator in the server. The client 
initiates the test signal generation sending it as UDP to the client via Internet 
infrastructure, giving the start reference time at the same moment to the timer- 
autocorrelator. The test signal's waveform is provided to the autocorrelator. After the 
reception in the server, the signal is bounced back immediately as UDP via Internet 
with the known measurable delay of the transponding process. Upon the signal 
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reception in the client, the stop time is issued to the timer-autocorrelator. The time 
between the transmission and the reception of the test signal is equal to the network 
delay of the UDP channel. Moreover, the autocorrelation between the transmitted and 
the received waveform may be done in order to evaluate the eventual degradation of 
the signal quality by means of the network transfer. Time measurement, 
autocorrelation, transmission, reception and transponding are very well known 
processes in software engineering and the expert skilled in the art could implement. 

A still further embodiment will now be discussed. The network infrastructure 
continues to become more and more advanced through the introduction of the new 
technologies. In 1993, the Asynchronous Transfer Mode (ATM) has been introduced 
to enable the very high data throughput rate for the high reliability and high speed 
connections consolidating data, audio and video traffic over a single broad-bandwidth 
line. It offers the cost-effective multiple services over the same network whereby 
ATM transmission equipment is easily configured to adapt variable traffic patterns 
and priorities for various tasks: LAN interconnect, frame relay, high-speed data 
services and IP routing. 

ATM brings completely new possibilities for telemedicine and particularly for 
the implantable devices follow-up. IP over ATM will be the most important variant of 
the infrastructure utilized for the public network. ATM is a connection-oriented 
technology utilizing the Layer 2 cell switching of the Open Systems Interconnection 
protocol that is the hardware based. In contrary to that, IP is a connectionless protocol 
whereby IP networks use software-based Layer 3 packet routing. From the practical 
point of view, the most convenient for teleprogramming would be the ATM 
connection between the client and the server, despite of the fact which one of the two 
comprises the programmer. It may happen that commercial interest will rise among 
the medical institutions and small physicians offices in such a manner that they will 
have multiple tasks and therefore cheap ATM connection for teleradiology, 
telepathology, teleconference, telesurgery and other various telemedicine applications. 
Nevertheless, several IP over ATM protocols are in development. Particularly the 
Internet Engineering Task Force (IETF) has been active developing the RFC 1577 
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being the first true IP over ATM technology called Classical IP (CLIP) and emulating 
the IP subnetwork in an ATM infrastructure. One or more logical internetworking 
subnetworks are connected to a backbone subnetwork comprising routers attached to 
an ATM node. ATM Forum has developed LAN emulation (LANE) providing the 
5 protocols used by the clients to dynamically setup and tear-down ATM data carrying 

connections over the backbone network. It has a lack of security standards for the 
public networks. Ipsilon Networks developed the IP switching being actually a 
combination of intelligent IP routing with high-speed ATM switching, having major 
lack of scalability. ATM Forum developed a novel approach to the overlay combining 

10 the LANE dynamic setup process with the another routing protocol called Next Hop 

Resolution Protocol (NHRP). Finally, Multiprotocol Label Switching (MPLS) is the 
emerging technology of the IETF utilizing the concepts of the IBM's label switching 
in ARIS protocol and of the TAG switching of Cisco. 

FIG. 12 illustrates the an implantable device teleprogramming system utilizing 

15 the MPLS protocol in the future modern public network infrastructure based upon the 

ATM. The pacemaker expert workstation and the pacemaker programmer have the 
capability of data, audio signal, and video signal transmission and reception. 
Accordingly, they would practically integrate the technology of the teleconference 
and the technology of the teleprogramming. That also requires the capability of audio- 

20 video compression and decompression (MPEG-2). A multimedia network access 

concentrator may be used in order to concentrate the video and data traffic onto one 
network interface. Intra-domain routing protocols identify a predetermined path 
between any two points. A label is associated with the specific path and appended to 
the IP packet by a Label Edge Router. The packet is forwarded to a Label Switch 

25 Router (LSR) wherein the label is read and the packet is forwarded to its destination. 

Dynamic establishment and removal of label switched paths is controlled by the Label 
Distribution Protocol which allows transparency of the topology information between 
the nodes. The forwarding function is done within the ATM switch because MPLS 
eliminates the need for a router subnetwork structure utilizing the LSR as an ATM 

30 switch. The result is the IP switching at the speed of the ATM backbone switching 
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enabling the real time multi-channel exchange of the biomedical signals, transmission 
of the high-resolution medical images and finally the audio-visual contact between the 
expert advisor and the remote patient site. Though the programming wand is 
disclosed, it will be not necessary in the future. Telemetry circuits are in the process 
of development which will enable the connection between the patient and the 
programme within the range of everyday room activities. Accordingly, the physician 
will be able to login into the patient-s device and check its function. The physician 
would be automatically alarmed about the occurrence of the hazardous arrhythmia. 

Thus there is disclosed a system permitting the remote communication with a 
medical device. The system particularly may permit the remote communication such 
that one or more device experts such as physicians and more experienced device 
users may be aware of the communication and provide guidance for the subsequent 
interpretation and programming of the device. The system may include a medical 
device adapted to be implanted into a patient; a server PC communicating with the 
medical device, the SPC having means for transmitting data across a dispersed data 
communication pathway (Internet); anda client PC having means for receiving data 
transmitted across a dispersed communication pathway from the SPC. In certain 
configurations the the server PC may have means for transmitting data across a > 
dispersed data communication pathway (Internet) along a first channel and a second 
channel; and the client PC may have means for receiving data transmitted across a 
dispersed communication pathway from the SPC along a first channel and a second 
channel. It should be understood the above desription is only illustrative of the 
present invnetion. 
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What is claimed is: 



1 . A system for remote communication with a medical device comprising 

a medical device, the medical device adapted to be implanted into a patient; 
5 a server PC communicating with the medical device, the SPC having means 

for transmitting data across a dispersed data communication pathway (Internet); and 
a client PC having means for receiving data transmitted across a dispersed 

communication pathway from the SPC. 



10 2. The system according to claim 1 wherein the SPC having means for 

transmitting data across a dispersed data communication pathway (Internet) along a 
first channel and a second channel; and 

the client PC having means for receiving data transmitted across a dispersed 
communication pathway from the SPC along a first channel and a second channel. 

15 

3. The system according to claim 1 further comprising a programmer, the 
programmer coupled to the SPC and providing a means for interacting with an 
medical device. 



20 4. The system according to claim 3 wherein the means for interacting with an 

medical device comprise a means for testing the medical device. 

5. The system according to claim 4 wherein the programmer has means for 
sensing a connection interruption between the client and server or the server and 
25 programmer. 



6. The system according to claim 5 wherein the programmer has means for 
terminating any testing being performed by the medical device should the means for 
sensing the connection interruption sense a connection interruption. 



30 
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7. The system according to claim 3 wherein the means for interacting with an 
medical device comprise means for interrogating the medical device 

8. The system according to claim 3 wherein the means for interacting with an 
medical device comprise means for downloading data from the medical device 

9. The system according to claim 3 wherein the means for interacting with an 
medical device comprise means for uploading data to the medical device 

10. The system according to claim 1 wherein the client PC has means for 
communicating across a dispersed data communication pathway (Internet) to the SPC. 

1 1 . The system according to claim 1 wherein the client PC has means for ■* 
classifying client users as either a first client user or a second client user. 

12. The system according to claim 1 wherein the client PC has means for - 
classifying client users as either a first client user or a second client user or a third 
client user or a fourth client user. 

13. The system according to claim 1 1 further comprising mean for providing a 
first user interface to the first client user upon the classification of the client user as a 
first client user. 

14. The system according to claim 13 further comprising mean for providing a 
second user interface to the client user upon the classification of the client user as a 
second client user. 

15. The system according to claim 1 1 further comprising mean for limiting access 
to the medical device upon the classification of the client user as a first client user. 
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16. The system according to claim 1 5 wherein the mean for limiting access to the 
medical device upon the classification of the client user as a first client user comprises 
mean for permitting the first client user to only observe medical device operation. 

17. The system according to claim 12 further comprising the medical device has 
means for storing information, and wherein the mean for limiting access to the 
medical device upon the classification of the client user as a first client user comprises 
mean for permitting the first client userto only retrieve information stored in the 
medical device. 

18. The system according to claim 12 wherein the means for classifying client 
users and limiting access to the medical device based on the classification comprises 
means for classifying and client users and limiting access to the medical device to 
only 

19. The system according to claim 1 wherein the means for transmitting data 
across a dispersed data communication pathway (Internet) comprises means for 
transmitting data in one or more data packets. 

20. The system according to claim 19 wherein the one or more data packets each 
have a confirmation receipt whereby the client, upon receipt of each of the one or 
more data packets, transmits back to the SPC that the one or more data packets was 
received. 

21. The system according to claim 19 wherein the one or more data packets do not 
have a confirmation receipt. 

22. The system according to claim 1 wherein the means for transmitting data 
across a dispersed data communication pathway (Internet) comprises means for 
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transmitting data in one or more data packets using a first data protocol and a second 
data protocol. 

23. The system according to claim 22 wherein second data protocol includes data 
packet receipt information. 

24. The system according to claim 1 wherein the server has means for accepting a 
first handshake data packet from the client. 

25. The system according to claim 1 wherein the first handshake data packet from 
the client instructs the server to only accept data from the IP address of the client. 

26. The system according to claim 1 wherein the server has means for limiting the 
acceptance of instructions to the server by the client at the first IP address. 

27. The system according to claim 1 wherein the SPC has means for 
communicating to the medical device through an electromagnetic coupling 

28. The system according to claim 27 wherein the electromagnetic coupling 
comprises a head transmitting and receiving electromagnetic signals to the medical 
device 

29. The system according to claim 1 wherein the SPC has means for transmitting 
an applet to the client. 

30. The system according to claim 29 wherein the applet comprises an executable 
program which performs tasks on the client without having to send a request back to 
the server. 
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3 1 . The system according to claim 1 wherein the medical device has means for 
generating Java applets. 

32. The system according to claim 1 wherein the server has means for determining 
the delay between data sent from the server to its receipt by the client, the client 
having means for displaying to a user the determined delay at pre-selected times. 

33 A system for communicating with an medical device comprising: 

a programmer, the programmer receiving data from an implanted device; 

a means for dis-assembling the received data into formatted packets of data for 
transmission through a dispersed communication pathway (Internet); 

means for transmitting the formatted through a dispersed communication 
pathway (Internet). 

34. The system according to claim 33 further comprising a means for re - 
assembling formatted packets of data into re-produced data, the re-produced data 
corresponding to the received data. 

35. The system according to claim 34 further comprising a PC to display the re- 
produced datawherein the PC has inputs to input commands to the implanted device. 
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